Processing system and method for tranmitting data

ABSTRACT

A method for exchanging data between a first and a second functional unit is described, which comprises the following steps: in a first handshake procedure, data is exchanged corresponding to a communication thread (TID) selected by the first functional unit (I), while independently in a second handshake procedure, information relating to a status of at least one communication thread is exchanged from the second (T) to the first functional unit (I). The information enables the first functional unit (I) to anticipate the possibility of exchanging data for the at least one communication thread.

The invention relates to a method for transmitting data as described inthe introductory part of claim 1.

The invention further relates to a processing system as described in theintroductory part of claim 4.

Method for exchanging data between a first and a second functional unit,comprising the following steps

in a first handshake procedure, data is exchanged corresponding to acommunication thread (TID) selected by the first functional unit (I),while independently

in a second handshake procedure, information relating to a status of atleast one communication thread is exchanged from the second (T) to thefirst functional unit (I) characterized in that,

the information enables the first functional unit (I) to anticipate thepossibility of exchanging data for at least one communication thread.

The first handshake wherein data is exchanged from a first to a secondfunctional unit may be part of a chain of data transactions from asource functional unit via one or more intermediate functional units toa destination functional unit. The first functional unit, initiating thefirst handshake is also denoted as initiator or initiator functionalunit The second functional unit is denoted as target, or targetfunctional unit.

With such a chain of data transactions a message can be sent by thesource functional unit to the destination functional unit. The messagemay comprise a command an addresses and/or other data. The destinationfunctional unit may on its turn send a message to the source functionalunit. A functional unit can be any unit involved in a data stream forexample a unit which performs operations on data, such as a CPU, a DSPor a VLIW, or a unit for storing data such as a memory, or a unit fortransmitting data such as a router or an interface.

A split protocol is defined as a protocol wherein transactions are splitin a request and a response. After a transmission of a request iscompleted from a source functional unit to the first intermediatefunctional in the communication path the source functional unit canproceed with a next transmission, instead of having to wait for aresponse to that request from the destination functional unit. Thedestination or any intermediate functional unit will start a separatearbitration procedure if necessary to give a response. A split busprotocol is more efficient when a response generation at the slave takestime. Pipelining allows a master to have multiple outstanding requests(i.e., requests waiting for a response). All transactions within thesame communication thread are ordered: Requests are executed by theslave in the same order as the requests for those responses were issuedby a master, and responses are delivered in the same order as therequests for those responses were issued by a master.

A communication thread can be used to identify a data stream betweendifferent processes or data streams originating from different sourcefunctional units. Transactions with different communication threads donot have any ordering constraints.

A message sent by a source functional unit may comprise a command, anaddress and/or other data. It is forwarded via one or more intermediatefunctional units until it arrives at the destination functional unit.The destination functional unit may on its turn send a message to thesource functional unit.

U.S. Pat. No. 6,182,183 provides a link level protocol for exchangingthe message between two subsequent functional units in the path from thesource functional unit to the destination functional unit. According tothe known protocol a master functional unit produces information, e.g. acommand (Cmd), an address (Addr), or data (DataReq) and at the same timeprovides an identification of the thread (ReqThreadID) to which theinformation belongs. Likewise the slave functional unit may provideinformation (DataResp), and indicate the stream to which it belongs byan identification RespThreadID.

In addition the slave can provide the master information relating to thestatus of a communication thread (ReqThreadBusy). This allows the slaveto indicate to the master that it cannot take any new requestsassociated with certain threads. In one embodiment, the ReqThreadBusysignal is a vector having one signal per thread, and a signal assertedindicates that the associated thread is busy. Analogously a responsethread busy (RespThreadBusy) signal allows the master to indicate to theslave that it cannot take any responses associated with certain threads.

The ThreadBusy information (ReqThreadBusy and RespThreadBusy) preventsthat the initiator attempts to initiate a transmission in vain. Insteadit can initiate a transmission for another communication thread if thatis available. Hence, this information contributes to a more efficientcommunication. However, if all threads are busy communication is stillblocked.

It is a purpose of the invention to provide an improved method andprocessing system. The improved method according to the invention ischaracterized by the characterizing portion of claim 1. The improvedprocessing system is characterized by the characterizing portion ofclaim 4.

In the improved method according to the invention the information givenby the target functional unit is not only indicative whether a requestor a response for a certain thread can be handled at the moment that theinformation is provided but the information also enables the firstfunctional unit (I) to anticipate the possibility of exchanging data forat least one communication thread.

In this way a scheduler in the initiator functional unit is betterenabled to schedule in which order transmissions for the differentcommunication threads should be handled.

In the embodiment of claim 2 information indicative for the fillingdegree of a buffer for a particular communication thread indicates theinitiator how long data transmission can go on before a buffer overflowoccurs. This enables the first functional unit (I) to anticipate atermination of the possibility of exchanging data for that communicationthread.

In the embodiment of claim 3 the information indicative for an expectedwaiting time enables the first functional unit (I) to anticipate whennew data will be provided or when new data can be accepted. The secondfunctional unit may for example need a relatively long processing timeto calculate a result vector from two input vectors. It may indicate toa fist functional unit to which the result vector will be transmitted anindication for the remaining processing time. A scheduler in that firstfunctional unit may then schedule a data transmission at a time that theresult vector is expected to be ready.

For example it may schedule the data transmission at a time that bufferoverflow tends to occur for another communication thread. Likewise itmay provide this indication to a first functional unit which provides aninput vector, which may use this information in its scheduling.

By providing information to the first functional unit (I) which enablesit to anticipate the possibility of exchanging data for a communicationthread it can better schedule transmissions for the differentcommunication threads. This makes it possible to reduce the occurrenceof a simultaneous unavailability of all communication threads.

The present invention is in particular relevant for a system on siliconimplemented as plurality of functional units in a network. Systems onsilicon show a continuous increase in complexity due to the everincreasing need for implementing new features and improvements ofexisting functions. This is enabled by the increasing density with whichcomponents can be integrated on an integrated circuit. At the same timethe clock speed at which circuits are operated tends to increase too.The higher clock speed in combination with the increased density ofcomponents has reduced the area which can operate synchronously withinthe same clock domain. This has created the need for a modular approach.According to such an approach the processing system comprises aplurality of relatively independent, complex modules. In conventionalprocessing systems the modules usually communicate to each other via abus. As the number of modules increases however, this way ofcommunication is no longer practical for the following reasons. On theone hand the large number of modules forms a too high bus load. On theother hand the bus forms a communication bottleneck as it enables onlyone device to send data to the bus. A communication network forms aneffective way to overcome these disadvantages. The communication networkcomprises a plurality of partly connected nodes. Messages from a moduleare redirected by the nodes to one or more other nodes. This impliesthat many information streams will pass between a pair of an initiatorand a target unit. The present invention facilitates the scheduling ofthese streams.

These and other aspects are described in more detail with reference tothe drawings. Therein:

FIG. 1 shows a conventional method for exchanging data,

FIG. 2 schematically shows a method for exchanging data according to theinvention,

FIG. 3 shows a first embodiment of the method according to theinvention,

FIG. 4 shows a second embodiment of the method according to theinvention,

FIG. 5 shows a first example of the first embodiment,

FIG. 6 shows a second example of the first embodiment,

FIG. 7 shows a first example of the second embodiment,

FIG. 8 shows a second example of the second embodiment,

FIG. 9 shows a network comprising a plurality of functional unitsaccording to the invention.

FIG. 1 shows a conventional method for exchanging data.

Therein a first processing unit (P) provides an identification for acommunication thread TID, data for that thread DATA and signals validitywith a signal VALID. If the second processing unit can accept the threadit signals this with the signal ACCEPT.

FIG. 2 schematically shows a method according to the invention forexchanging data between a first and a second functional unit. The methodcomprises the following steps. In a first handshake procedure data (HSD)is exchanged corresponding to a communication thread (TID) selected bythe first (I) and the second functional unit (T). At the same timesecond information is exchanged in a second handshake procedure (HST)from the first (I) to the second functional unit (T) relating to astatus of at least one communication thread from the second (T) to thefirst functional unit (I). The information enables the first functionalunit (I) to anticipate the possibility of exchanging data for the atleast one communication thread.

The first handshake for transmission of the data can be either a classichandshake, as used in VCI, OCP (as will be illustrated in more detail inFIGS. 5 and 7), or an extended handshake in which feedback is providedon whether a transaction can proceed or not on a TID (see FIGS. 6 and8). This basic group of signals is extended with another group ofsignals, as an independent dialog to gather information on whichcommunication threads data can be scheduled without stall.

The first and the second handshakes HSD and HST are independent and thusthey can proceed in parallel. The information collected from the secondhandshake HST is used by the initiator to schedule communications fordifferent communication threads efficiently.

In a practical example the second handshake HST comprises the exchangeof a first signal INFO TID, a second signal INFO VALID, and a thirdsignal INFO INFO. The first signal INFO TID is indicative for aparticular communication thread. The second signal INFO VALID indicateswhether the signal INFO TID is valid or not. The third signal INFO INFOcan have different meanings, depending on the further implementation ofthe protocol. It may for example indicate an expected waiting time, i.e.indicating when data will become available or when data can be acceptedfor the thread identified with the signal INFO TID. Otherwise the signalmay for example indicate the filling degree of a buffer. Thisinformation helps a data consuming initiator to estimate how long a dataproducing target can continue with providing data from its buffer. Thismay be a best case estimate or a worst case estimate. A worst caseestimate can be made calculating the time necessary the read the presentcontents of the buffer. A best case estimate can be made by assumingthat the data producing target keeps supplying data at a certain rate.In practice the target may in the mean time generate new data. Likewiseit may help a data producing initiator to estimate how long a dataconsuming target can continue with accepting data. Also, this is a worstcase estimate. In practice the target may in the mean time process datastored in its buffer. A best case estimate can be made taking an averagerate into account with which the data is processed.

In the scheme, shown in FIG. 3, the initiator requests (polls for)communication thread information from the target. Information isrequested for one communication thread at a time, by indicating acommunication thread with the INFO TID signals and rising INFO VALID.The target provides information on INFO INFO signals (in this case in afixed number of cycles).

For this scheme multiple different handshakes schemes can be defined.One example is to have a valid signal (INFO VALID) to announce thatinformation about the communication thread identified with INFO TID isrequested. It will be held high during a predetermined time-interval,e.g. one cycle, and the response (INFO INFO) will come in fixed numberof cycles (e.g., 1). Another example, which allows the target to delaythe response is to keep the valid signal (VALID INFO) high until aresponse is coming. The response is signaled with an accept signal for asingle cycle in which also the response is given (INFO INFO).

Examples of the polling scheme where the initiator is a producer and aconsumer are shown in more detail in FIGS. 5 and 6, respectively. For aproducer initiator, the consumer target may for example provideinformation indicative for the amount of buffer space available toaccept data on the given communication thread. A producer target may forexample provide a consumer initiator, how much data is available in thegiven communication thread, or indicate with which frequency it providesnew data.

In the second scheme, shown in FIG. 4, the target drives the flow ofinformation towards the initiator. An example of the information thatcan be provided to the initiator consists of updates, differential orabsolute, (similar to interrupts) to how many handshakes can beperformed on a given communication thread without stall. Differenthandshake schemes are also possible, as in the previous extension.

Examples of the interrupt scheme where the initiator is a producer and aconsumer are shown in FIGS. 7 and 8, respectively. For a producerinitiator, the consumer target could notify the initiator on each newempty buffer place (or group of buffer places) that becomes available ona given communication thread. For a consumer initiator, the producertarget could notify the initiator about each new data element (or groupof data elements) that becomes available.

The two proposed schemes are both applicable in different contexts. Ifthe initiator is a CPU, the polling scheme (which checks everyappropriate communication thread to decide which will be scheduled next)may have lower cost. The interrupt scheme would require notifications tobe treated as interrupts whose handling has high cost because theyrequire context switches.

For a dedicated functional unit, the interrupt scheme, which is similarto flow control, has a low cost because it will only cause a counterupdate for example. The communication thread scheduler has always thelatest necessary information and can proceed immediately.

As opposed to this, the poll scheme, where the dedicated functional unitpolls for information, either consumes precious cycles before ascheduling decision, or it uses incomplete information, thus, loweringthe scheduling quality.

In case a functional unit does not support these extensions, it canstill be used with each of the extended schemes presented above, becausethe basic handshake is not changed and the additional group of signalscan be ignored by defaulting INFO VALID to a low value.

Connecting an initiator not supporting such an extension with a targetsupporting one of these extensions can be done by simply ignoring theinfo group. For the polling scheme, the target will not get any poll,and therefore will not produce any information.

For the interrupt scheme, the produced information will be ignored.Connecting an initiator supporting one of these extensions with a targetnot supporting such an extension requires the initiator to be designedsuch that it can still schedule communications even without theinformation from targets.

To connect an initiator functional unit supporting the polling schemewith a target functional unit supporting the interrupt scheme, a smalladapter must be inserted between the two functional units wherenotifications from the targets are stored to be delivered to theinitiator when it polls for information. Also the data sent from theproducer to the consumer must go through this adapter to update thehandshake information. For example, in the case of a target consumer,the buffer filling (to be reported to the initiator by the adapter) willincrease with the transferred data, and in the case of a targetproducer, the data availability (to be reported to the initiator by theadapter) will decrease with the transferred data.

Similarly, connecting an initiator supporting the interrupt scheme witha target supporting the polling scheme requires an adapter in betweenwhich polls the target and notifies the initiator about changes.

The two extensions cover the only two cases in which information aboutcommunication threads can be obtained via an additional handshake: (a)initiator polling for information, and (b) initiator getting notifiedabout any change in the target

The proposed scheme is relevant for device and system-levelcommunication protocols which allow communication on independentcommunication-threads, such as VCI and OCP. It extends the existinglink-level schemes to allow collecting information from target. Thisinformation is used by the initiator to obtain a better scheduling ofcommunication threads on a link.

The proposed two schemes cover the only two cases in which informationabout communication threads can be obtained via an additional handshake:(a) initiator polling for information, and (b) initiator gettingnotified about any change in the consumer.

FIG. 9 schematically shows a data processing system, which comprises anetwork connecting a plurality of functional units. The processingsystem is arranged to transmit data and a communication threadidentifier for said data according to a split protocol along acommunication path (indicated by arrows) from a source functional unitSFU to a destination functional unit DFU via one or more intermediatefunctional units IFU1, . . . , IFU5. The communication path includes atleast a pair of an initiator and a target unit as illustrated withreference to one of the FIGS. 2 to 8. By transmitting the data togetherwith a communication thread identifier, multiple unrelated transactions,having mutually different communication thread identifiers can evolveindependently.

It is remarked that the scope of protection of the invention is notrestricted to the embodiments described herein. Neither is the scope ofprotection of the invention restricted by the reference numerals in theclaims. The word ‘comprising’ does not exclude other parts than thosementioned in a claim. The word ‘a(n)’ preceding an element does notexclude a plurality of those elements. Means forming part of theinvention may both be implemented in the form of dedicated hardware orin the form of a programmed general purpose processor. The inventionresides in each new feature or combination of features.

1. Method for exchanging data between a first and a second functionalunit, comprising the following steps in a first handshake procedure,data is exchanged corresponding to a communication thread (TID) selectedby the first functional unit (I), while independently in a secondhandshake procedure, information relating to a status of at least onecommunication thread is exchanged from the second (T) to the firstfunctional unit (I) characterized in that, the information enables thefirst functional unit (I) to anticipate the possibility of exchangingdata the for at least one communication thread.
 2. Method according toclaim 1, wherein the information is indicative for the filling degree ofa buffer reserved for the at least one communication thread.
 3. Methodaccording to claim 1, wherein the information is indicative for anexpected waiting time before a request relating to the at least onecommunication thread can be handled.
 4. Processing system comprising afirst and a second functional unit, the processing system being arrangedto exchange data corresponding to a communication thread (TID) selectedby the first functional unit (I) in a first handshake procedure, whileindependently exchanging information relating to a status of at leastone communication thread from the second (T) to the first functionalunit (I) in a second handshake procedure characterized in that, theinformation enables the first functional unit (I) to anticipate thepossibility of exchanging data for the at least one communicationthread.
 5. Processing system according to claim 4 comprising a pluralityof functional units in a network, the processing system being arrangedto transmit data and a communication thread identifier for said dataaccording to a split protocol along a communication path from a sourcefunctional unit (SFU) to a destination functional unit (DFU) via one ormore intermediate functional units (IFU), including a first functionalunit and a second functional unit.